refactor: use wasm-harness - #397
Merged
Merged
Conversation
sinui0
force-pushed
the
refactor/wasm-harness
branch
from
May 20, 2026 18:22
c9de7ad to
a9df2a3
Compare
Contributor
|
@sinui0 , could you commit the usage notes to the repo? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switch wasm test/bench runner to wasm-harness
Summary
Replaces the
wasmtime --wasi threadsrunner withwasm-harness, which executeswasm32-wasip1[-threads]binaries under a chosen engine (wasmtime, V8/d8, SpiderMonkey/sm) via a bundled WASI polyfill. Enables runningcargo test/cargo benchagainst the same JS engines used in browser-targeted benches, without source changes.Changes
.cargo/config.toml[target.wasm32-wasip1]entry mirroring the threaded target'srustflags(atomics, bulk-memory, mutable-globals, simd128, 4 GiB max memory).wasm32-wasip1andwasm32-wasip1-threadsnow userunner = "scripts/wasm-runner.sh".scripts/wasm-runner.sh(new, executable)nprocon Linux,sysctl hw.ncpuon macOS, fallback1) and exportsWASM_HARNESS_ENV_RAYON_NUM_THREADS=<cores>.wasm-harnessforwards env vars prefixed withWASM_HARNESS_ENV_into the guest with the prefix stripped, so rayon seesRAYON_NUM_THREADSwithout polluting the host shell.WASM_HARNESS_ENV_RAYON_NUM_THREADSis respected (user override).execswasm-harnesswith cargo-supplied args.Usage
Prerequisites:
cargo install wasm-harness. For JS engines,npm i -g jsvu && jsvuto installv8/smshells. With no engine selected,wasm-harnesspicks the first available from$PATH/~/.jsvu/bin.Engine can also be selected per-invocation by editing the script to pass
--engine <name>, or by settingWASM_HARNESS_ENGINEin the environment.Notes
wasm-harnesspropagates a default whitelist of host env vars into the guest; theWASM_HARNESS_ENV_prefix is the explicit escape hatch used here to setRAYON_NUM_THREADSwithout depending on whitelist contents.--inherit-envis available onwasm-harnessif you'd rather forward every host env var instead of using the prefix.num_threads()will ignoreRAYON_NUM_THREADS— that's a per-bench concern, not a runner one.